The development of Very Large Scale Integrated (VLSI) chips can be divided into two broad design phases: logical (or front end) and physical (or back end). The logical design phase deals primarily with the functional aspects of the VLSI chip, while the physical design phase focuses on implementing the chip. A chip designer in the logical design phase typically starts with a high level specification and refines it through a number of levels of abstraction. The chip is then implemented in the physical design phase. The designer is careful to maintain functional equivalence between successive levels of specification, and analyzes and verifies that each lower level specification, with its added implementation details, satisfies the design objectives defined for the chip.
FIG. 1 outlines the different levels of design specification for a typical VLSI chip. A functional behavioral specification 30 defines the functional behavior of the system and describes how the system responds to external inputs. This level of specification implies little about the physical implementation of the chip. A register transfer level (RTL) specification 32 defines the system functionality with clocking explicit and accurate cycle-by-cycle. A logical gate level netlist specification 34 details system functionality thereby making all of the cell elements that implement the system and their connectivity explicit. A physical gate level netlist specification 36 is functionally equivalent to the logical gate level netlist specification 34 but with a re-partitioned design hierarchy and cell selections that are more likely to satisfy backend physical constraints and the desired chip operating speed. A GDSII mask level specification 38 defines the actual layout geometries (e.g. polygons and paths) that implement the chip.
With advances in silicon process technology, more and more circuit functionality that was previously implemented in separate silicon devices is now integrated into a single silicon chip. The benefits of this System-On-Chip (SOC) approach to VLSI designs are obvious—lower system cost, lower power consumption, and higher operating speeds.
But the highly integrated nature of SOC designs present many challenges to development teams. SOC designs normally contain a large number of functional design blocks. The blocks can be legacy blocks inherited from previous projects, intellectual property (IP) blocks purchased from third party suppliers, or new blocks designed in-house. Each functional block may have one or more operating clocks and may be designed to run at different frequencies. It is not uncommon to have a large number of different operating clock domains in a SOC design.
As the design specification is refined during the physical design phase, the impact of layout interactions and constraints on chip performance become clearer. The designer may not only re-partition the functional hierarchy from the logical design phase but may also substitute or transform basic cell elements to better satisfy the performance objectives of the chip. These changes, although they should leave the circuit functionally equivalent to its logical design phase specification, may re-arrange or even disperse clock domains that were once local thereby resulting in additional delays that can directly impact both effective clock operating frequencies and clock domain interactions.
Analyzing the impact of these physical design phase specification refinements and validating that the chip will still meet performance objectives is greatly complicated in both VLSI and SOC chips due to their typically high clock counts. It's not enough to simply validate each clock, a problem that scales linearly with the clock count, but the designer must also validate clock domain interactions across all of the distinct operating conditions and test modes of the chip. This is a challenge that has exponentially increasing complexity with the number of distinct clock domains increasing. Generally, clock interaction verification is performed by leveraging other analysis steps in three different levels of specification; (1) register transfer level (RTL), (2) logical gate level netlist and (3) physical gate level netlist.
FIG. 2 shows a block diagram of a typical functional simulation process for clock interaction verification. Functional simulation addresses the functional behavior of the design and is typically applied to either the register transfer level (RTL) or the logical gate level netlist. Furthermore, functional simulation evaluates how the design responds to a pre-defined input stimulus and compares the response to an expected behavior. Functional simulation can also be used to check the correctness of basic clock behavior and clock interactions. Referring to FIG. 2, a simulation test bench 50 is an input stimulus set-up for the functional simulation and drives the functional simulation process. A design specification 52 defines the functional description of the design and can be either the register transfer level (RTL) design files 54 or the logical gate level netlist files 56. Simulation model files 58 define the functional simulation models for all the cell elements in the gate level netlist specification including primitive cells and special blocks such as memory. Configuration files 60 are set-up files specific to the functional simulation software program. The functional simulation 62 is the functional simulation software program, while simulation output files 64 are the results from the functional simulation analysis runs whereby clock interaction signals can be observed, tracked and analyzed. Run-time log files 66 report the status and errors of the simulation throughout the entire analysis runs.
Functional simulation is a dynamic analysis tool with results that are stimulus dependent. The completeness or coverage of the analysis is dependent upon the completeness of the stimulus input data. If functional simulation is the only method employed to analyze clock interactions, it is possible that all required checks for all relevant scenarios may not be performed. In addition, selecting all of the appropriate probe points to correctly observe the interaction between clock domains in the functional simulation is extremely challenging. An error may be missed even if a complete set of stimulus vectors are offered.
FIG. 3 shows a block diagram of a static timing analysis process for clock interaction verification. Static timing analysis can be performed on either logical or physical gate level netlist specifications. It traverses through the physical connectivity of the design and reports the longest and shortest path delays originating from defined clock sources. General clock interaction connectivity can be derived and checked by checking each path that crosses the clock domain.
Referring to FIG. 3, timing constraint and exception files 80 define the path exception and timing constraints for the static timing analysis runs. The path exception includes multiple-cycle paths and false paths. Input design specification files 82 are the gate level netlist files for the timing analysis run. The files 82 can be either logical gate level netlist files 56 or physical gate level netlist files 86. Timing model files 88 contain the timing attributes for all the cell elements including memory in the gate level netlist specification. The timing attributes include delay transition arcs, delay values, timing constraints, clocking pins, storage type such as flop or latch, and the cell's functional expression. These timing attributes are the basis for describing the timing behavior of each cell element and are needed in the static timing analysis process. Run-time control files 90 contain software tool specific data for controlling the run-time behavior of the static timing analysis software program. Static timing analysis 92 is the actual static timing analysis software program used in the simulation. Interconnect parasitic files 94 are used for a physical gate level netlist and contain the parasitic capacitances and resistances of all the interconnect nets in the design. The parasitic data is extracted from the design layout. Delay annotation files 96 contain the delay data of all the nets and cells in the design. This is only needed when a net delay calculation is performed outside the static timing analysis software program. Timing analysis report files 98 are the main analysis output and include the longest and shortest path delays and their slack times in terms of meeting the timing constraints. The run-time log files 100 report the errors and informative status tracking of the static timing analysis runs.
There are key limiting factors to the usefulness of static timing analysis. The size and complexity of the SOC designs often require an enormous amount of computing resources and generate large volumes of output data in the static timing analysis process. This is especially the case when analyzing clock interactions where all of the relevant paths crossing clock domains need to be separately identified and analyzed.
Another method in the current art for design analysis is a pure RTL based analytical method that analyzes the RTL specification and the clock domains assigned to the RTL elements. No detailed timing is evaluated because this is a pre-synthesis technique that doesn't have access to the detailed timing in the gate level netlist. But clocks and clock domain interactions can be inferred and some simple synchronization analysis can be applied. A drawback to this technique is its very limited analytic utility and lacking access to the physical structure and detailed timing information about the circuit.
In VLSI chips and especially in SOC there is a need to identify and verify the clock interaction in various operating modes completely and correctly. The current state of the art is a combination of functional simulation and static timing analysis. Each method is limited by a lack of completeness and an inability to handle design size and complexity. Furthermore, in the current state of the art, either the correct stimulus and probe points, or the correct paths for the analysis must be identified to be accurate and thorough.